[WIP] Separate SwiftKit into SwiftKitCore and SwiftKitFFM #300
Conversation
I think that's the right call, but let's avoid getting the method via reflection and instead just give the cleanup something to run, rather that reflection trick and it'll be fine 👍 |
| } | ||
| // val test by getting(JvmTestSuite::class) { | ||
| // useJUnitJupiter("5.10.3") | ||
| // } |
| @@ -12,7 +12,7 @@ | |||
| // | |||
| //===----------------------------------------------------------------------===// | |||
|
|
|||
| package org.swift.swiftkit; | |||
| package org.swift.swiftkitffm; | |||
There was a problem hiding this comment.
| package org.swift.swiftkitffm; | |
| package org.swift.swiftkit.ffm; |
I'd do a sub package like this; and everything we do in this module should be contained in this package then
| @@ -16,7 +16,7 @@ plugins { | |||
| id("build-logic.java-application-conventions") | |||
| } | |||
|
|
|||
| group = "org.swift.swiftkit" | |||
| group = "org.swift.swiftkitffm" | |||
There was a problem hiding this comment.
| group = "org.swift.swiftkitffm" | |
| group = "org.swift.swiftkit.ffm" |
let's do subpackage, that's "typical"
| @@ -0,0 +1,21 @@ | |||
| package org.swift.swiftkitffm; | |||
There was a problem hiding this comment.
Just a heads up to remember the license headers
| import java.lang.foreign.MemorySegment; | ||
| import java.util.concurrent.ThreadFactory; | ||
|
|
||
| public interface AllocatingSwiftArena extends SwiftArena { |
There was a problem hiding this comment.
Very nice, I think this makes sense; and the factories on the interface as well
|
|
||
| try { | ||
| // Use reflection to look for the static destroy method on the wrapper. | ||
| Method method = clazz.getDeclaredMethod("destroy", long.class); |
There was a problem hiding this comment.
We can pass a Function rather than Class to the constructor and store that; We shouldn't need to resort to reflection here AFAICS.
| id("build-logic.java-application-conventions") | ||
| } | ||
|
|
||
| group = "org.swift.swiftkitcore" |
There was a problem hiding this comment.
So the group for them all is org.swift.swiftkit
and the artif
| group = "org.swift.swiftkitcore" | |
| group = "org.swift.swiftkit" |
but the artifact id will come from the module name, which will be SwiftKitCore and SwiftKitFFM -> swiftkit-core + swiftkit-ffm
Setting those is done in publishing { publications { maven(MavenPublication) if I read this correctly... Either way -- the group ID remains the same for all those and you don't need to worry about the artifact IDs yet
| if (selfType != null && selfPointer != null) { | ||
| System.out.println("[debug] Destroy swift value [" + selfType.getSwiftName() + "]: " + selfPointer); | ||
| SwiftValueWitnessTable.destroy(selfType, selfPointer); | ||
| } |
|
|
||
| public class SwiftKit { | ||
| public class SwiftFFM { |
There was a problem hiding this comment.
I think we can call this type SwiftRuntime now as it is the runtime entrypoints we call using ffm... No need to call it FFM in the type -- it is in the ffm module (or rather .foreign module)
| public static final boolean TRACE_DOWNCALLS = Boolean.getBoolean("jextract.trace.downcalls"); | ||
|
|
||
| private static final String STDLIB_MACOS_DYLIB_PATH = "/usr/lib/swift/libswiftCore.dylib"; | ||
|
|
There was a problem hiding this comment.
Very nice, that's a nice centralization of this logic.
Let's make the class final
The goal of this PR is to separate SwiftKit into two modules:
SwiftKitCore: A module that supports non-FFM memory management and uses JNI for any downcalls.SwiftKitFFM: A module that uses FFM for allocation of memory and downcalls.It is still early work in progress. But the vision I have is that
SwiftInstancenow provides adestroymethod that the JNI code can then override to call into the VWT from Swift and deallocate the pointer, while FFM can still use the existing VWT calling.